A processing system network, such as a computer network, is a combination of network nodes and servers that are capable of communicating with one another over one or more communication paths or links. Each network node, as well as each server, is either an individual processing system, such as a computer, or another processing system network. Network nodes and servers communicate in order to share resources, such as databases and data files, processing applications, hardware peripherals, communication links and the like.
Each server typically performs at least one of three general functions or services, namely, file management, printing or communications. Network portal devices are typically used to couple network nodes and servers together to facilitate resource sharing. The portal device functions as a junction point through which the aforementioned server functions are requested, accessed and utilized by one or more network nodes.
Assume for example that a particular application, APPL.sub.-- X, is resident to a single server. A user wishing to access APPL.sub.-- X simply identifies it by name through a particular portal device. This is commonly referred to as "session establishment." This procedure is used to "name-access" (i.e., identify) APPL.sub.-- X during "log-on" to the server. In the event the server and the application are available, the network node gains access to APPL.sub.-- X and utilizes it. Otherwise, access is denied.
It is often desirable to make multiple copies of a particular application available on a single processing system network. Assume APPL.sub.-- X is a popular application and that the server upon which it resides does not have the processing capacity to efficiently support all the network nodes wishing to access and utilize it. In response to such circumstances, additional copies of APPL.sub.-- X are typically made available on other servers.
While these additional copies of APPL.sub.-- X should increase server efficiency, as well as over-all processing system network throughput, this has rarely been the case in practice. This is due largely because the procedures for accessing a particular copy of APPL.sub.-- X have become significantly more complicated.
Assume APPL.sub.-- X is resident on two or more servers. If a user wishes to request, access and utilize APPL.sub.-- X, the name of the particular copy of the application must be identified. One approach requires that each duplicate copy of the particular application be given a different name (e.g., APPL.sub.-- X1, APPL.sub.-- X2, . . . , APPL.sub.-- Xn). The varied names are then associated with each of their respective servers. A user wishing to utilize this particular application is thus required to know the specific name of any duplicate copy that might be accessed.
Maintaining this information is at best difficult. Nonetheless it often becomes necessary to do so in the event a current server running one or more copies of an application fails or, alternately, if the processing response time of the current server is unacceptable. Users typically, and understandably so, have trouble remembering the various names of the applications. Accessing a particular application often becomes a time consuming and annoying process as the burden of selecting a server running the application, which hopefully provides an acceptable response time, falls upon the user. The user's selection of servers becomes a trial and error process. This difficulty is compounded when considering that one or more application copies are sometimes moved from one server to another.
There accordingly exists a need in the art to simplify the requirements for a user to gain access to a single one of multiple copies of a particular application on a processing system network, wherein the multiple copies reside on different servers.
There exists a further need to substantially minimize a user's involvement in selecting a server to run a particular application with as prompt a processing response time as is then available.